The approaches described in this section could be pursued, but are not necessarily approaches that have been previously conceived or pursued. Therefore, unless otherwise indicated herein, the approaches described in this section are not prior art to the claims in this application and are not admitted to be prior art by inclusion in this section.
In a network such as a public wireless local area network (PWLAN) or “hotspot”, user devices such as a laptop, cell phone or personal digital assistant (PDA) are typically authorized upon connection to the network and an appropriate billing method applied. For example referring to FIG. 1 which is an illustrative network diagram of a PWLAN designated generally 100 a user device 102 connects to a network gateway 104 providing access to a network 106 such as the Internet. The user device 102 can communicate with a host device 108, for example providing an application function. For example the gateway 104 can be a Subscriber Service Gateway (SSG) of the type provided by Cisco Technologies Inc of San Jose, Calif. and as described in the document “index.html” at the location “/univercd/cc/td/doc/solution/sesm/sesm—33x” on the domain “cisco.com” on the World Wide Web.
In order to enforce user authentication and provide payment service for example for Internet access, the SSG communicates with a gateway controller application provided locally at 110. The gateway controller application can include, for example, a Subscriber Edge Service Manager (SESM) 112, a domain name server proxy 114 and an authorization, authentication and accounting (AAA) server 116.
Referring to FIG. 2 which is a flow diagram illustrating the steps involved in connection of a user device to such a network, at step 200 a user device requests access to an application hosted at 108 authorization and at step 202 the SSG 104 either permits the request or redirects the user's HTTP traffic to the SESM portal 112. At step 204 the SESM carries out an authorization transaction with the user device and at step 206. At step 208 the SSG interacts with the AAA server 116 to establish session parameters such as the policy to be applied to the session and at step 210, once authentication is established, the user device is allowed to connect with the network and select for use the desired' service such as Internet service or provision of an application function by a host.
One transaction that may be requested by the user device 102 is a domain name resolution service requiring connection to a domain name server (DNS). The operation of DNS is well understood by the skilled reader and well documented in previous existing documentation and therefore is only described in summary here for the purpose of ease of understanding. In particular a name server or DNS server for example as shown at 118 in FIG. 1 maintains a database of address (A) records associating domain names of the form, for example, www.aaa.bbb with a corresponding IP address of the form xxx.xxx.xxx.xxx. Accordingly the user device needing to access a network location such as host 108 described by a domain name can retrieve the IP address by sending an appropriate DNS request. In practice DNS services are typically distributed amongst multiple name servers and DNS requests may be transferred from higher domain name servers down to lower level domain name servers in a hierarchical manner.
The DNS transaction can be further understood with reference to FIG. 3 which is a flow diagram showing the steps involved and FIG. 4 which is a schematic diagram of a DNS request. At step 300 the user device sends a DNS request packet and at step 302 the SSG receives a packet and recognizes it as a DNS request. All DNS requests are received on UDP port 53 allowing simple recognition by the SSG. At step 304 the SSG redirects the DNS request to the DNS proxy 114. As is well known, the DNS proxy sends out a proxy DNS request with itself as source address such that DNS responses are received at it. This reduces the risk of malicious interception of DNS transactions which could take place if the user device were connected directly with the DNS server. At step 306 the DNS proxy sends a proxy DNS request to the DNS server. At step 308, the DNS request is received at the DNS server which may involve the request being passed through a hierarchy of servers as appropriate and at step 310 a DNS response is sent from the ultimate DNS server back to the DNS proxy, containing a resolved IP address. At step 312 the DNS response is received at the DNS proxy and forwarded by the SSG to the user device which can then apply for access to the resolved IP address.
The nature of a DNS packet can be seen from FIG. 4 as including a DNS header 400 and records 402, 404, 406 of known type comprising, for example, an A record, a CNAME record and a text (TXT) record. The CNAME and TXT records are able to carry payloads of approximately 110b and 220b respectively.
It is known, however, to use the DNS protocol to tunnel traffic over DNS and hence obtain free access in the event that an SSG does not require authorization for a DNS transaction. In particular use is made of the payload available in the record fields to package IP packets. A specially configured DNS client is implemented on the user device and a specially configured DNS server is provided remotely on the Internet allowing composition of packaged DNS requests and responses and parsing and decomposition of received DNS requests and responses.
Referring to FIG. 5, which is a flow diagram illustrating the steps involved in tunneling traffic over DNS, at step 500 the user device sends a packaged DNS request and step 502 the SSG redirects the DNS request to the DNS proxy. At step 504 the DNS proxy sends a proxy DNS request via a local DNS server which is received at the specially configured DNS server by virtue of the hierarchical nature of DNS at step 506. For example referring to FIG. 1, a configured DNS server 120 may be provided on the network 106 to which the DNS request is delegated by local DNS server 118.
At step 508 the specially configured DNS server parses or decomposes the DNS request to obtain the packaged traffic. At step 510 the DNS server then interacts with the desired host for example host 108 and at step 512 composes a packaged DNS response. The packaged DNS response is received via the local DNS server at the DNS proxy and forwarded as any normal DNS response via the SSG to the user device where it is parsed by the configured client application to find the packaged traffic.
In many instances authorization is not required for DNS transactions such that an unauthorized user can package an IP session within multiple DNS request and response transactions. Furthermore it is often not possible to block DNS transactions. For example in many PWLANs, the SESM carries a white list of DNS hosts with which a user device may communicate with prior to authorization. In order to communicate with these hosts the host name needs to be resolved to an IP address by performing a DNS “transaction”. By virtue of the hierarchical nature of DNS the request will be handled down to the specially crafted DNS server. Alternatively or in addition the SSG may itself not require authorization for access to certain DNS servers.